Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1993/93-12

Text File | 1995-12-31 | 121KB | 3,569 lines

Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: mac-primer vol 1  menus
Message-ID: <[e-mail]>
In-Reply-To: Your message <QCFBCA11@ouradnik> of 30 Nov 93 22:33:55 GMT
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 43
Date: 1 Dec 93 04:10:03 GMT

Mike Ouradnik on miscreant popup menus:

>   What I found by chance was that I had to check the
>   PRELOAD box

Resources are not always read into memory, but frequently
used ones and ones used at startup should be, so the
preload attribute is available for all resources.

Not only should all menus be preloaded, they should also
_never_ be marked as purgeable, as the menu manager doesnt
wanna take the trouble to deal with disk I/O while fielding
a menu hit.

Why not? Remember that the screen behind the menu is
cached so that it can be restored by the menu mangler
when the menu pops up, if I/O were done, and a problem
arose, then an alert window would have to be displayed,
which is real trouble for the 128k original Mac.
Probably could be handled today, but not under low
memory situations, so KISS is the basic answer.

>   This was not mentioned anywhere in the chapter

Well it sure is mentioned in Inside Mac, which you really
should be reading along with any third party book.

>   I don't understand why it is required here yet not for
>   the other menus.

Menus set up by the menu manager get detached, and are thus
not resource handles anymore, not sure if you did things
in a way that allowed these popups to still be resource
handles, but if you some how managed to avoid detaching
them and they got purged then that would explain a lot
of what you saw.

Bone up on Resources in general, Menus in particular, but
use the real IM (or NIM), not the Primer.  Couldnt hurt
to sneak a peek at the tech notes as well.
--
dana s emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail] ("Richard K. Wolf")
Subject: MacTCP examples ... ???
X-Sender: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 17
Date: 1 Dec 93 18:22:19 GMT

Hey everyone,

Can anyone point me in the direction of some simple MacTCP source?  I know
fancy source exists for things like tn3270, etc., but I don't need anything
that complex.  I just want something with no frills, but which shows the
proper ways to open and use TCP streams.  Something really small and
digestable would be ideal.

Thanks in advance!

Richard K. Wolf
[e-mail]
Small Systems Group
Computer Center
University of Illinois at Chicago












Path: ucivax!gateway
From: [e-mail]
Subject: Request Info
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 4
Date: 1 Dec 93 18:32:45 GMT
X-Envelope-to: [e-mail]

I just purchased Think C++ 6.0 and would like to know if there is a user group, someone to whom I can write to with questions, ftp sites with C source code written for Think C, or any other information you can give me.  Thank you.

            Alexander Dvorak
            email: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Jon Wiederspan)
Subject: Extras for Think C++ 6.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 1 Dec 93 19:18:51 GMT

What kinds of extras (third party additions or shareware/freeware) are there
for the new Think C/C++?  I used to have things like ProjectPrinterFKEY,
Think Back, and Marker Control.  Do these still work?

Total Novice










Path: ucivax!gateway
From: [e-mail] (Stefan Arentz)
Subject: Re: Extras for Think C++ 6.0
X-Sender: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 30
Date: 1 Dec 93 20:37:38 GMT

>What kinds of extras (third party additions or shareware/freeware) are there
>for the new Think C/C++?  I used to have things like ProjectPrinterFKEY,
>Think Back, and Marker Control.  Do these still work?
>
>Total Novice

Hi Jon,

I am working on a shareware system extension called "THINK Power". The
hottest features are:

 - Popup Menus with funtions/methods and header files.
 - Kissing (Auto hiliting of [], {} and () pairs)
 - Tiling and Stacking windows
 - Extensions (a la BBEdit)
 - Shortcuts. You can change the command keys to navigate through text windows.

You can get a copy of the first beta from the umich mac archive. I really
need some good bug reports, so if you have the time...

Greetings,
 -- Stefan Arentz


----------------------------------------------------------------------------
Stefan Arentz            -- Software Constructor --        [e-mail]
----------------------------------------------------------------------------
                    Scrub-a-dub-dub with Barney in the tub!












Path: ucivax!gateway
From: [e-mail] (Pete Gontier)
Subject: Re: Extras for Think C++ 6.0
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Jon Wiederspan" at Dec 1, 93 7:18 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 14
Date: 1 Dec 93 21:40:08 GMT

> What kinds of extras (third party additions or shareware/freeware)
> are there for the new Think C/C++?  I used to have things like
> ProjectPrinterFKEY, Think Back, and Marker Control.  Do these still
> work?

Symantec must have seen all these utilities, decided there was user
demand, and forced the developers to work on adding these features to
the environment properly. It now prints the project window, compiles
in the background, and does markers better. Unfortunately, these
features apparently cost more than money -- they cost the stability
of the C++ compiler, too.

--
 Pete Gontier // EC Technology // [e-mail]










Path: ucivax!gateway
From: [e-mail] (Steve Morris)
Subject: please un-subscribe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 1 Dec 93 21:58:51 GMT


Eithor my mail isn't making it, I`m sending to the incorrect address, or I'm
being ignored. I would like off this list and have been trying to say as much
to [e-mail] but am having no luck. Could someone correct me
or forward my request to the correct address? I would appreciate it. It's painful
enough to have had to sell my Mac and leave Mac development without frequent
think-c reminders that others are still having fun.

Regards
--
Steve Morris
<[e-mail]>
Phoenix Technologies LTD
38 Sidney Street
Cambridge, MA 02139
[phone]










Path: ucivax!gateway
From: [e-mail] (Robert Wisdom)
Subject: Re: Request Info
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 2 Dec 93 05:58:07 GMT

On xxx, 1 Dec 1993, [e-mail] wrote:

> I just purchased Think C++ 6.0 and would like to know if there is a user
> group, someone to whom I can write to with questions, ftp sites with C
> source code written for Think C, or any other information you can give me.

> Thank you.

    I just got the updater off sumex (anonymous ftp to
sumex.stanford.edu).  The name is symantec-cpp-updater-6.01.hqx (maybe,
this is close though), and is in the /dev directory.  Maybe I should get
Symantec C++ now :-)  You might want to pick it up too.

>             Alexander Dvorak
>             email: [e-mail]

    Robert Wisdom










Path: ucivax!gateway
From: [e-mail] (Jim Lynch)
Subject: Re: MacTCP examples ... ???
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 2 Dec 93 09:14:26 GMT

>Hey everyone,
>
>Can anyone point me in the direction of some simple MacTCP source?  I know
>fancy source exists for things like tn3270, etc., but I don't need anything
>that complex.  I just want something with no frills, but which shows the
>proper ways to open and use TCP streams.  Something really small and
>digestable would be ideal.
>
>Thanks in advance!
>
>Richard K. Wolf
>[e-mail]
>Small Systems Group
>Computer Center
>University of Illinois at Chicago

If digestible size, I'd like a peek, as well. Thanks...
-Jim











Path: ucivax!gateway
From: [e-mail]
Subject: saving preferences
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
Newsgroups: fa.think-c
Lines: 23
Date: 2 Dec 93 10:01:25 GMT
X-Envelope-to: [e-mail]

I like to save my prefs in a file.
In system 7 this is done in another directory as in system 6.
Also the directory names in local system versions are different.
Is there a standard procedure to do this, or an example program,
ar have I to do it all myself, e.g. checking system version,
and directorynames.

thanks, Gerrit.

From:        Gerrit Polder
             CPRO-DLO
             P.O. Box 16
             6700 AA   Wageningen
             The Netherlands                         \\    //
                                                      \\  //
Phone:       [phone]                             \/
Fax:         [phone]                             /\
Email:       [e-mail]   _                //  \\
HAM-Radio:   PA3BYA                 / \              //|  |\\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~/   \               |  |
                                        \     _________| #|_________
                                         \~~~/
                                          \_/










Path: ucivax!gateway
From: [e-mail] ("Wolfgang Breitling (403"), "7085)"@ics.uci.edu
Subject: Re: saving preferences
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "[e-mail]" at Dec 2, 93 10:01 am
Mailer: Elm [revision: 70.85]
Newsgroups: fa.think-c
Lines: 13
Date: 2 Dec 93 13:36:01 GMT

>
> I like to save my prefs in a file.
> In system 7 this is done in another directory as in system 6.
> Also the directory names in local system versions are different.
> Is there a standard procedure to do this, or an example program,
> ar have I to do it all myself, e.g. checking system version,
> and directorynames.
>
Have a look at ftp.brown.edu. It is the home of an archive of Think Class
Library classes contributed by various people on the net. One of the classes
does preference file reading and writing and as far as I remember. it has a
non-TCL version as well. In the worst case you can copy the relevant code
out of the class. Look in pub/tcl/classes (or something like that).










Path: ucivax!gateway
From: [e-mail] ("Wolfgang Breitling (403"), "7085)"@ics.uci.edu
Subject: Re: MacTCP examples ... ???
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Jim Lynch" at Dec 2, 93 9:14 am
Mailer: Elm [revision: 70.85]
Newsgroups: fa.think-c
Lines: 13
Date: 2 Dec 93 13:38:14 GMT

>
> >Hey everyone,
> >
> >Can anyone point me in the direction of some simple MacTCP source?  I know
> >fancy source exists for things like tn3270, etc., but I don't need anything
> >that complex.  I just want something with no frills, but which shows the
> >proper ways to open and use TCP streams.  Something really small and
> >digestable would be ideal.
> >

The TCL class archives at ftp.brown.edu contain a class dealing with TCP. I
haven't looked inside but I would assume it should contain code dealing with
those basics.










Path: ucivax!gateway
From: [e-mail] ("Peter E. Britton - Ext. 234")
Subject: Unsubscribe
X-Sun-Charset: US-ASCII
Message-ID: <[e-mail]>
Content-Length: 81
Newsgroups: fa.think-c
Lines: 3
Date: 3 Dec 93 04:00:24 GMT

Please remove my name from the subscription list for this group.

[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 3 Dec 93 10:23:47 GMT

I'm writing a small application using TCL. I use ReadAll to put some data in
a handle called myData. Then, when user select a command, a routine manipulate
the data and puts them in another handle called newData (which is local).
Finally I assign the new handle to the old one like:
     myData = newData;
when i step out this routine, everything crashes the first time that I send
any messages to gDesktop. Debugging, I discovered that newData has the same add
ress of global gDesktop, inside the local routine, and therefore, when I assign
to myData the same address, something weird happens...
I'm looking for hints about the following problems:
1)How can I just manipulate data (ASCII in this case) without having to assing
to an EditText object.
2)How can I avoid to assign same addresses to different items?
3)How do I know which item the TCL strcture keeps global, and which local?

I know it's a lot, thank you in advance

Rodolfo Cardarelli










Path: ucivax!gateway
From: [e-mail]
Subject: A silly question of icons
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 3 Dec 93 11:56:58 GMT

Message written at Thu Dec  2 23:01:36 GMT 1993

I am sure that the answer is simple, but it is causing me great pain.
I have an application which I would like to have its own icon.  I have
added the necessary icons with SAres, and RedEdit shows that they are
there.  The problem is that it does not show the icon, never.  I did this
before and it does show the icon, but for this new applicaton it does not
work.  Could some kind person give me some clues?

==John










Path: ucivax!gateway
From: [e-mail] ("Jeffrey K. Carney")
Subject: Re: A silly question of icons
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 25
Date: 3 Dec 93 15:01:25 GMT

>I have an application which I would like to have its own icon.  I have
>added the necessary icons with SAres, and RedEdit shows that they are
>there.  The problem is that it does not show the icon, never.  I did this
>before and it does show the icon, but for this new applicaton it does not
>work.  Could some kind person give me some clues?

1.  Make sure your icons are linked to your file signature.  The easiest
way is to open you bundle bits resource on EXTENDED VIEW.  This will map
the whole icon signature structure, and you can make changes as you need
to.

3.  Have you assigned the proper file signature (corresponding to the one
you assigned in RES) to your project itself while still in the compiler?
You must impose the match; it is not done automatically for you.  Use the
"Set Project Type" command in the Project menu.

2.  Have you tried rebuilding your desktop?  [Hold down command-option
during startup; or force-quit finder and hold down those keys as finder
automatically launches itself again.]  If the desktop data file contains an
old icon for the file signature (which it might if you're using a signature
you've used before), you'll get screwed up results.

Anyone else?












Path: ucivax!gateway
From: [e-mail] ("Mark D. Nagel")
Subject: ADMIN: delay in responses
Message-ID: <28977.754936154@rdatasys>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: Relational Data Systems, Irvine, CA
Lines: 9
Date: 3 Dec 93 16:46:07 GMT
Phone: [phone]

I'd like to apologize for not responding to messages to
think-c-request since this past weekend.  In order for me to manage
the list, I have to dial into the UC Irvine terminal server.  Since
this is the last week of the quarter, doing that has become nearly
impossible due to modem congestion.  I will hopefully be able to
deal with the backlog this weekend.  Your patience is appreciated.

Mark











Path: ucivax!gateway
From: [e-mail] ("David A. denBoer")
Subject: Animating Text
X-Sender: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 20
Date: 6 Dec 93 02:28:59 GMT

You may or may not have seen this question floating around lately, but I'll
take a stab at this list as well.
My application needs to be able to let the user animate text on any color
background, and have any colored text.  Coloring the text and background is
no problem.  Animating the text is.  Using simple calls to DrawString, and
offsetting the string in any given direction (eg up and left), I get fairly
smooth animation, but depending on the font (and size), the text sometimes
bleeds, or leaves a trail behind it the same color as the text.  It sometimes
looks neat, but it is not what we need.
Is there a better way to draw and move text around than what I said above?  I
thought of drawing it to a PicHandle, and giving it an oversized background so
it does not bleed, but this proves to be too memory intensive at larger font
sizes.
Please lend a hand, as this has been a headache for a few weeks.

David A. denBoer                                Computer Consultant/Programmer
University of Manitoba                       Computer Services - User Services
     "Ducks Unlimited - Conserving ducks to blow the sh*t out of them."












Path: ucivax!gateway
From: [e-mail]
Subject: Re: A silly question of icons
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 6 Dec 93 09:06:12 GMT

Message written at Sun Dec  5 08:23:52 GMT 1993

Thank you everyone who took the trouble to answer my naive question.
The commonest answer was to rebuild the desktop.  I suspected that
that was the thing I needed but I did not know how to do it!  Anyway
doing it did not cause the icons to appear.  So it is back to checking
all the other suggestions.

==John










Path: ucivax!gateway
From: [e-mail]
Subject: ShowInit
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 32
Date: 7 Dec 93 21:53:16 GMT
X-Envelope-to: [e-mail]

Yesterday, I bought the 'Macintosh C Programming Primer, Vol II' to learn more
about how to write inits.  However, some of the code for ShowInit.c wouldn't
compile.  Three lines gave 'syntax error'.  Could anyone tell me why?
----------------------------------
    OpenPort(&myPort);
    colorFlag=0;
    if (!(BitTst(&ROM85,7-hasCQDBit)))   /*This line gives 'syntax error'
*/
    {
        theMainDevice = MainDevice;
        theDepth= (*(*theMainDevice)->gdPMap)->pixelSize;
        if (theDepth>=minColorDepth)
        {
            if ((theIconHdl = (Handle)GetCIcon(iconID)) !=0L)
                colorFlag =1;
        }
    }
---------------------------------
dh = (myH << 1) ^ checksumConst;
myH = ((dh == myCheck) ? (myH):(firstX));  /* This line gives 'syntax error' */
destRect.bottom = myPort.portRect.bottom - bottomEdge;
---------------------------------
myH += ((moveX == -1) ? (defaultMoveX):(moveX));  /* This line gives 'syntax
error' */
myCheck = (myH << 1) ^ checksumConst;
---------------------------------

Also, is there a list of corrections for this book?  I am using Think C 6.0.1.
Thanks for your help.

Alexander
email: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: ShowInit
Message-ID: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of 7 Dec 93
 21:53:16 GMT
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 38
Date: 8 Dec 93 00:28:18 GMT

Unlike Think Pascal, Think C only shows the line in error.
Luckily, you can freely rearrange that line to enable the
compiler to show you what it doesnt like.

Change

>       if (!(BitTst(&ROM85,7-hasCQDBit)))

so each token is on a seperate line

if
(
!
(
BitTst
(
&
ROM85
,
7
-
hasCQDBit
)
)
)

then re-compile, the errant token will be plainly identified.

After a while you get used to the time it takes to splat the tokens and
reassemble them.  One might be tempted to use a binary search strategy, but I
have found its usually fastest to go splat.

The diagnosis is up to you, that particular error is often triggered by a
missing type definition, maybe you have neglected to #include some crucial
header file.
--
dana s emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail] (Jim Lynch)
Subject: Re: ShowInit
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 43
Date: 8 Dec 93 12:10:56 GMT

>Unlike Think Pascal, Think C only shows the line in error.
>Luckily, you can freely rearrange that line to enable the
>compiler to show you what it doesnt like.
>
>Change
>
>>       if (!(BitTst(&ROM85,7-hasCQDBit)))
>
>so each token is on a seperate line
>
>if
>(
>!
>(
>BitTst
>(
>&
>ROM85
>,
>7
>-
>hasCQDBit
>)
>)
>)
>
>then re-compile, the errant token will be plainly identified.
>
>After a while you get used to the time it takes to splat the tokens and
>reassemble them.  One might be tempted to use a binary search strategy, but I
>have found its usually fastest to go splat.
>
>The diagnosis is up to you, that particular error is often triggered by a
>missing type definition, maybe you have neglected to #include some crucial
>header file.
>--
>dana s emery <[e-mail]>

We should get Eric Slosser to put a "splat"er (and an un"splat"er) in his
PopUpFuncs program.

-Jim











Path: ucivax!gateway
From: [e-mail] (Jeremy Creighton Ahouse)
Subject: containers in Think C++ or Think C
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 32
Date: 8 Dec 93 18:30:11 GMT

My favorite feature in Apple's HyperTalk language is the easy way that
containers can be manipulated... these are essentially variable length
arrays that store text, and allow you to:
        put "any string" into myContainer
        put "any string" after char 27 of myContainer
        put "any string" into word 1 of myContainer
        put "any string" after item 5 of myContainer
        put "any string" before line 3 of myContainer

        etc... and ofcourse you can get any of thes substrings as easily...

        have any of you all written this kind of thing as a C++ class or a
ThinkClassLibrary class?

        Thanks,
                Jeremy


        :::::::::::::::::::::::::::::::::::::::::::
        Jeremy Creighton Ahouse
        Biology Dept. & Center for Complex Systems
        Brandeis University
        Waltham, MA 02254-9110

        [phone]
        email: [e-mail]
        Mail from Mac by Eudora 1.3.1 RIPEM/PGP accepted.

        "Si un hombre nunca se contradice, sera porque nunca dice nada"
                - Miguel de Unamuno












Path: ucivax!gateway
From: [e-mail] (Danny Thomas)
Subject: reporting syntax errors (was Re: ShowInit)
X-Sender: [e-mail].
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 46
Date: 8 Dec 93 21:39:57 GMT

>>Unlike Think Pascal, Think C only shows the line in error.
>>Luckily, you can freely rearrange that line to enable the
>>compiler to show you what it doesnt like.
...
>We should get Eric Slosser to put a "splat"er (and an un"splat"er) in his
>PopUpFuncs program.

How about get Symantec to report the token!
Surely it can't be very hard and more descriptive error output has got to
be better** particularly for novices.

And some other syntax-checkable things I've long wanted
   when a type-mismatch is reported how about saying
     "I'm expecting a *char for 'variable_x'
      but the assignment expression is **char"
     Again this can't be hard - the compiler has the info and only has to
     reformat its internal representation of types.
   and a pragma so you can specify that a particular function argument
     is a printf/scanf-style format string and which of the remaining
     arguments corresponds to the first item in that format specification.
     Apart from the ability to check the standard library functions,
     such a pragma would allow checking of user-defined stdarg-type
     functions. I often define a simple abort() or message() function
     that uses a format-string to give a detailed diagnostic, but I'm a
     bit paranoid and many of these error() messages aren't invoked during
     my informal testing so it may not be till months later that a error
     occurs and I find a corrupted diagnostic message that isn't so helpful
     simply because I made a mistake in the format string.


cheers,
Danny Thomas

PS although I've loaded Symantec C++ onto my hard-disk I haven't had a
chance to use it. If it incorparates some of those suggestions, great, but
it shouldn't have taken this long.


** and because TC (pre 6) stops at the first error (a long-complained about
mis-feature), it is simply not the case that a error leads to a cascade of
diagnostics making it hard to figure out the significant messages. It may
be that the TC developers thought that continuing after an error made the
parsing routines too complex, but I don't know of any justification for not
providing as useful error an message as possible.












Path: ucivax!gateway
From: [e-mail] (The Only Cow)
Subject: Color Classic Screen
X-Sender: [e-mail]
Message-ID: <[e-mail]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 18
Date: 9 Dec 93 00:56:50 GMT

Can anyone tell me if apple has provided any routines to turn off the
screen on a Color Classic as is done automatically by the system software
after a preset time?

Does apple keep some archive of code specific to various machines that I
should be looking at?

Thanks for yer help...

-Chris

------------------------------------------------------------------------------
   "To error is human, but to really foul things up, you need a computer."
                   Send questions, comments, flames, etc. to:
                    Chris Harris / [e-mail]
                      PGP Signature availible via finger...












Path: ucivax!gateway
From: [e-mail] (Jim Lynch)
Subject: Re: reporting syntax errors (was Re: ShowInit)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 9 Dec 93 00:57:29 GMT

>>>Unlike Think Pascal, Think C only shows the line in error.
>>>Luckily, you can freely rearrange that line to enable the
>>>compiler to show you what it doesnt like.
>...
>>We should get Eric Slosser to put a "splat"er (and an un"splat"er) in his
>>PopUpFuncs program.
>
>How about get Symantec to report the token!
>Surely it can't be very hard and more descriptive error output has got to
>be better** particularly for novices.

Good idea.

I tried it last year and before that, in the days of TC4.

I was ignored both times, however my suggestion for a "find ALL the errors,
generate warnings, double clicking takes me to that line" was not ignored.

Phil...?

We need for Think C and C++ to hilite the TOKEN at which the error was
found, not just the line.

Thanks Phil.

-Jim











Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: fix the bugs first (was reporting syntax errors)
Message-ID: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of 8
 Dec 93 21:39:57 GMT
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 22
Date: 9 Dec 93 15:21:59 GMT

>   How about get Symantec to report the token!

Lets encourage them to get the existing bugs in the: project
manager, debugger, and C++ compiler, fixed first.

Marketing people just love to add new features, its so much
easier than fixing bugs.

Please folks, dont ask S to fix stuff that has reasonable
workarounds, keep up the pressure on them to fix the bugs.

what do we want?     fix the bugs

when do we want it?  NOW!!!

fix the bugs
fix the bugs
fix the bugs
fix the bugs...
--
dana s emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail] (Jim Van Peursem)
Subject: Re: fix the bugs first (was reporting syntax errors)
Message-ID: <[e-mail]>
In-Reply-To: Your message of "09 Dec 1993 15:21:59 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 9 Dec 93 16:00:27 GMT


>>   How about get Symantec to report the token!
>
>Lets encourage them to get the existing bugs in the: project
>manager, debugger, and C++ compiler, fixed first.
>
>Marketing people just love to add new features, its so much
>easier than fixing bugs.

  This very true. But history shows that they usually release
a new version every year or two, and the rest of the time they
release bug fixes.

>Please folks, dont ask S to fix stuff that has reasonable
>workarounds, keep up the pressure on them to fix the bugs.

  So I'd disagree with this. Make any and all suggestions to
Symantec. They will probably get added to their list. But they
realize that they need to fix the bugs in the compiler first.
Have you _ever_ seen a x.1 version of any of their compilers?
I doubt they will do that before fixing most of the existing
bugs. That would be suicide.

---

-Jim











Path: ucivax!gateway
From: [e-mail] (Robert Ward)
Subject: XSYM files
Via: uk.ac.cambridge.mrc-applied-psychology; Thu, 9 Dec 1993 18:12:49 +0000
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 9 Dec 93 19:10:10 GMT


There doesn't seem to be any documentation on the XSYM files generated
by Symantec C++ (at least I haven't been able to find it). Is this
debugging information? If so, it only seems to be generated by the
C++, not the C compiler.

rob











Path: ucivax!gateway
From: [e-mail] ("Jeffrey K. Carney")
Subject: Getting Directory Info
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 9
Date: 9 Dec 93 19:51:56 GMT

I am generally having a hard time using low-level and high-level routines
when trying to get finder information about a directory.  The same routines
work fine when I pass data for a file, but return fnf when I pass data
about a directory.  This is true for FSpGetFInfo, HGetInfo, and
PBHGetFInfo.  IM says nothing about adjusting my data for a directory.  Has
anyone experienced this problem and found a way around it?  What I really
want to access is an FInfo record so I can toggle visibility.












Path: ucivax!gateway
From: [e-mail] (Pete Gontier)
Subject: Re: XSYM files
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Robert Ward" at Dec 9, 93 07:10:10 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 427
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 11
Date: 9 Dec 93 20:49:28 GMT

> (XSYM info) only seems to be generated by the C++, not the C compiler.

Perhaps you are looking at one project that is all C++ and one
project that is all C. The check-box which controls whether to export
the XSYM debugging info is a project-scope option. You can make your
C project export XSYM files if you like.

Sorry this doesn't help you with the file format...

--
 Pete Gontier // EC Technology // [e-mail]










Path: ucivax!gateway
From: [e-mail] (Felix Njeh)
Subject: unsubscribe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 9 Dec 93 21:03:11 GMT

unsubscribe










Path: ucivax!gateway
From: [e-mail] (Greg Ferguson)
Subject: Re: reporting syntax errors (was Re: ShowInit)
Message-ID: <9312092109.AA11565@vulture.>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 40
Date: 9 Dec 93 21:10:17 GMT

At  9:39 PM 12/8/93 +0000, Danny Thomas wrote:
>How about get Symantec to report the token!
>Surely it can't be very hard and more descriptive error output has got to
>be better** particularly for novices.
>
>And some other syntax-checkable things I've long wanted
>   when a type-mismatch is reported how about saying
>     "I'm expecting a *char for 'variable_x'
>      but the assignment expression is **char"
>     Again this can't be hard - the compiler has the info and only has to
>     reformat its internal representation of types.

This is an ages-old complaint and is extended to: "Why doesn't the compiler
fix the syntax and continue compiling if it knows what's expected?"

Probably because the "traditional" C compiler doesn't do that.

I believe that the Mac developer tools market is suffering because there is
too little competition. The (gasp) DOS world has several excellent
compilers and programming systems. (We're not arguing Mac O/S vs. Windows -
just Symantec C++ vs. Visual C++ and/or Borland C++ for Windows).

Just my $0.02.

Greg

--

Greg Ferguson

[e-mail]
Motorola, SPS


=============================================================
      We haven't inherited the earth from our ancestors.
        We've borrowed it from our children instead.
=============================================================












Path: ucivax!gateway
From: [e-mail] (Wally Wedel)
Subject: Re: fix the bugs first (was reporting syntax errors)
X-Sender: wwedel@vangogh
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 25
Date: 9 Dec 93 21:15:37 GMT


>  So I'd disagree with this. Make any and all suggestions to
>Symantec. They will probably get added to their list. But they
>realize that they need to fix the bugs in the compiler first.
>Have you _ever_ seen a x.1 version of any of their compilers?
>I doubt they will do that before fixing most of the existing
>bugs. That would be suicide.

Well in fact they don't get lots of bugs fixed! I (and others) reported the
problems with the strtod library function not being ANSI conformant (and in
fact broken) but it's still that way one major and one minor release later!

There are others too, of course. So it's not suicide to let some bugs slip
and the way that many companies evaluate bugs, enhancements, etc., is to
add them all to a list. When a developer goes into an area of the system
she looks at both bugs and enhancements and often does some of both.


Wally Wedel
U S WEST Communications
4001 Discovery Drive, Suite 370
Boulder, CO 80303-7813
Internet: [e-mail]  AppleLink: D5100   Voice: 303-541-6052












Path: ucivax!gateway
From: [e-mail]
Subject: Competition between mac compilers.
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
MIME-version: 1.0
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 15
Date: 9 Dec 93 21:26:25 GMT

reguarding a statement that dos machines have more competition between compiler
manufacturers than the mac market does, it appears that in the near future
that may be changing a little bit.  I found an article in macweek about a
month ago which mentioned that metroworks C/C++ is going to have a compiler
check flag to turn mac and powerPC binary compilation on and off.  The same
compiler would use one set of source code and compile a program for either
the mac, the powerPC, or (if I understood correctly) both at once (fat binaries).
The article went on to mention that the author thought it was both faster
and easier to use than its competitor.  Seeing how it bills itself as
a native c++ compiler for the mac I can only think of one competitor.
    I am anxiously waiting to see what happens, how easy it really
is (or isn't), and if they have a competitive upgrade offer.
Shawn Joyce
[e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: flex and bison
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 9 Dec 93 21:34:36 GMT

I've cobbled together new versions of Flex and Bison
under Symantec C 6.0 including a drag and drop
interface.  Since this is for my own use, I haven'
t included many niceties (only one file can be dropped,
no commandline flags, files must be in same directory
as flex/bison, etc.) but I think they work.  If there's
any interest (and this hasn't been done before) I may
improve them in the future.  If anyone is interested in
trying them out (warts and all), drop me a line.

Ian Dowell
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Jim Van Peursem)
Subject: Re: fix the bugs first (was reporting syntax errors)
Message-ID: <[e-mail]>
In-Reply-To: Your message of "09 Dec 1993 21:15:37 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 9 Dec 93 22:18:51 GMT


>There are others too, of course. So it's not suicide to let some bugs slip
>and the way that many companies evaluate bugs, enhancements, etc., is to
>add them all to a list. When a developer goes into an area of the system
>she looks at both bugs and enhancements and often does some of both.

  My comment was based on the fact that developers are very dissappointed
with the number of bugs in the compiler. It would be suicide to leave these
unfixed and release a new version. Sure there are going to be bugs in every
compiler, from release to resease. But they simply cannot (or should not if
they have any brains in management) leave the product as buggy as it is.

+---------------------------------------------------------------+
| Jim Van Peursem - Ph.D. Student - Ham Radio -> KE0PH          |
| Department of Electrical Engineering and Computer Engineering |
| Iowa State University - Ames, IA 50011                        |
| internet - [e-mail]  -or-  [e-mail]    |
+---------------------------------------------------------------+










Path: ucivax!gateway
From: [e-mail] (Danny Thomas)
Subject: compiler bugs and testing (was re: fix ... )
X-Sender: [e-mail].
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 25
Date: 9 Dec 93 22:30:35 GMT

Wally Wedel <[e-mail] writes
>Well in fact they don't get lots of bugs fixed! I (and others) reported the
>problems with the strtod library function not being ANSI conformant (and in
>fact broken) but it's still that way one major and one minor release later!
a comment that doesn't inspire total confidence...

regarding new compiler releases and bugs, I would be *very* interested to
know which if any C & C++ compiler testing suites were used prior to
shipping. Perhaps the evolving nature of C++ has made this difficult in
comparison to the ANSI C compiler, but I would consider it totally
negligent for any significant compiler company to not use at least one of
these testing suites. I gather they're not cheap (five-dollar-digits)
though.
    Mind you if it was my company that supplied the C++ suite used by
Symantec, I'm not sure I'd want the company name mentioned in Symantec ads:

 "And it doesn't stop with our code quality and reliabilty!!
  Symantec C++ is ROBUST and STANDARD!! It passes all phases of the
  BitWiddle C++ Compiler Conformance & Torture Tests - no other
  Macintosh C++ compiler can say that!!"

cheers,
Danny Thomas












Path: ucivax!gateway
From: [e-mail] (Kirk Crawford)
Subject: Got a list of bugs in TC6?
Message-ID: <[e-mail]>
Posted-Date: 9 Dec 93 14:36:59 U
Newsgroups: fa.think-c
Lines: 6
Date: 9 Dec 93 22:42:25 GMT

Subject:  Got a list of bugs in TC6?
While we are on the subject of bugs in Think C, does anyone have a
comprehensive list of the current bugs in Think C 6?













Path: ucivax!gateway
From: [e-mail] (Mike Greenawalt)
Subject: Re: reporting syntax errors
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 74
Date: 9 Dec 93 22:53:15 GMT

My $0.02 on the following discussion:

>  From: Greg Ferguson <[e-mail]>
>  Subject: Re: reporting syntax errors (was Re: ShowInit)
>  Date: 9 Dec 93 21:10:17 GMT
>  To: [e-mail]
>
>  At  9:39 PM 12/8/93 +0000, Danny Thomas wrote:
>  >How about get Symantec to report the token!
>  >Surely it can't be very hard and more descriptive error output has got to
>  >be better** particularly for novices.
>  >
>  >And some other syntax-checkable things I've long wanted
>  >   when a type-mismatch is reported how about saying
>  >     "I'm expecting a *char for 'variable_x'
>  >      but the assignment expression is **char"
>  >     Again this can't be hard - the compiler has the info and only has to
>  >     reformat its internal representation of types.

Mr Thomas is absolutely right!  It should not be hard for the compiler to tell
us what it thinks is wrong beyond "Syntax error".

The IBM C Set/2 compiler for OS/2 does this very well.  It's error messages
give that kind of information extensively, and it sure does help to quickly
understand the complaint and to make the fix.  This is particularly true when
the compiler is used in the WorkFrame/2 context where the error messages get
tied to the editor.

I have been a ThinkC user (dabbler) since V1.02, and I have thought it the
slickest and best project management/programming/compiling environment.  But I
do OS/2 stuff at work, and (I can't believe I'm saying this) the
OS/2+WorkFrame/2+C Set/2+IPMD combination is just as slick and I like it.

>
>  This is an ages-old complaint and is extended to: "Why doesn't the compiler
>  fix the syntax and continue compiling if it knows what's expected?"

No! Never! The compiler may have a very good notion of what would allow it to
continue at a given error, but there may be several choices, and how would it
know what *you* meant? Giving the compiler the power to "fix" the code will
inevitably lead to lurking, unexposed defects.

>
>  Probably because the "traditional" C compiler doesn't do that.
>
>  I believe that the Mac developer tools market is suffering because there is
>  too little competition. The (gasp) DOS world has several excellent
>  compilers and programming systems. (We're not arguing Mac O/S vs. Windows -
>  just Symantec C++ vs. Visual C++ and/or Borland C++ for Windows).
>
>  Just my $0.02.
>
>  Greg
>
>  --
>
>  Greg Ferguson
>
>  [e-mail]
>  Motorola, SPS
>
>
>  =============================================================
>        We haven't inherited the earth from our ancestors.
>          We've borrowed it from our children instead.
>  =============================================================

+---------------------------+--------------------------------------------+
| Mike Greenawalt           | [e-mail]                           |
| Metaphor, Inc.            | Metaphors be with you.                     |
| 1965 Charleston Road      |                                            |
| Mountain View, CA 94043   | These opinions are mine, not my employer's |
+---------------------------+--------------------------------------------+











Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: reporting syntax errors
Message-ID: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of 9 Dec
 93 22:53:15 GMT
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 39
Date: 10 Dec 93 04:15:59 GMT

Reporting the token in error is difficult for some forms of
compiler, but since splatting the line allows token
identification to be displayed in the present compiler, it
is clear that the necessary information available at the
time the error is being displayed.

The compiler could reference the token number, but when it
reports an error it does so to the editor module, right?

Surmise here, but I would guess that it is easier for the
editor to work on a line number basis than for it to work
on a token basis, considering that #defines and #includes
affect the token stream in ways the editor is otherwise
unaware of.

Maybe one of the authors of BBEdit or Alpha cares to
comment, they must have had to deal with this, having
authored a compatible editor module.

Frankly, I have no quibbles with doing an occaisional
splat now and then, if the editor puts in an interface
to help so much the better, but detailed feedback from
the compiler, much as it would be "nice", is not a very
high priority on my wish list at this time.

I want the damn bugs fixed before that particular luxury.

Maybe my umpteen years of dealing with mainframe compilers
(Fortran, Algol, Cobol, Mary, Basic (yes virginia, not
all Basic was interpreted) has taught me not to expect
any better.  There is a lesson to be learned in the
tyrany of Think Pascal's pretty printing editor (Think
Pascal attempts to show offending tokens): be careful what
you ask for, the gods will surely find a may to grant it
which will make you regret ever having had the nerve to
raise your voice.
--
dana s emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re: reporting syntax errors
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Dana S Emery" at Dec 10, 93 04:15:59 am
X-Mailer: ELM [version 2.4 PL21]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1095
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 29
Date: 10 Dec 93 14:21:05 GMT

> The compiler could reference the token number, but when it
> reports an error it does so to the editor module, right?
>
> Surmise here, but I would guess that it is easier for the
> editor to work on a line number basis than for it to work
> on a token basis, considering that #defines and #includes
> affect the token stream in ways the editor is otherwise
> unaware of.
>
> Maybe one of the authors of BBEdit or Alpha cares to
> comment, they must have had to deal with this, having
> authored a compatible editor module.

Presently, the compiler only provides a line number. However, the only
token information that the compiler need provide is the character
offset on the line of the start and end of the offending token; that's
something that requires zero effort by the editor (or compiler) to
report or display.


> be careful what
> you ask for, the gods will surely find a may to grant it
> which will make you regret ever having had the nerve to
> raise your voice.

Indeed, and it might appear that the present Symantec C++ compiler is
an example of this principle in action.

R.










Path: ucivax!gateway
From: [e-mail] (Jim Wintermyre)
Subject: Re: reporting syntax errors
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 10 Dec 93 16:28:03 GMT

Hi all,

Dana Emery notes:

> any better.  There is a lesson to be learned in the
> tyrany of Think Pascal's pretty printing editor (Think
> Pascal attempts to show offending tokens): be careful what
> you ask for, the gods will surely find a may to grant it
> which will make you regret ever having had the nerve to
> raise your voice.

Well, I just have to jump in and say that I *like* THINK Pascal's editor.  I
know right away when I've typed something in wrong.  It saves me a lot of time
fixing silly typing errors.  Sometimes I wish THINK C had the same thing, of
course with the option to turn it off (as THINK Pascal has).

Jim

[e-mail]
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Wally Wedel)
Subject: Re: compiler bugs and testing (was re: fix ... )
X-Sender: wwedel@vangogh
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 37
Date: 10 Dec 93 16:49:18 GMT


>regarding new compiler releases and bugs, I would be *very* interested to
>know which if any C & C++ compiler testing suites were used prior to
>shipping. Perhaps the evolving nature of C++ has made this difficult in
>comparison to the ANSI C compiler, but I would consider it totally
>negligent for any significant compiler company to not use at least one of
>these testing suites. I gather they're not cheap (five-dollar-digits)
>though.
>    Mind you if it was my company that supplied the C++ suite used by
>Symantec, I'm not sure I'd want the company name mentioned in Symantec ads:
>
> "And it doesn't stop with our code quality and reliabilty!!
>  Symantec C++ is ROBUST and STANDARD!! It passes all phases of the
>  BitWiddle C++ Compiler Conformance & Torture Tests - no other
>  Macintosh C++ compiler can say that!!"
>

Within the past month or so, there was a fairly long thread on this topic
in comp.lang.c++. It followed the release of the GNU test suite. The
consensus agreed with my personal experience that passing a test suite is
not a reliable indicator of how a language system will work in the "real
world". Too often a vendor concentrates on passing the test suite and
misses critical problems not covered in the test suite. All of this, of
course, begs the issue of errors in the test suite too!

I personally think that a solid well-run beta test is a better indicator of
product success. I sometimes have the feeling that that's what we're
conducting with Symantec C++ right now.


Wally Wedel
U S WEST Communications
4001 Discovery Drive, Suite 370
Boulder, CO 80303-7813
Internet: [e-mail]  AppleLink: D5100   Voice: 303-541-6052












Path: ucivax!gateway
From: [e-mail] (Greg Ferguson)
Subject: Re: Competition between mac compilers.
X-Sender: gregf@vulture
Message-ID: <9312101722.AA12114@vulture.>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 41
Date: 10 Dec 93 17:22:30 GMT

At  9:26 PM 12/9/93 +0000, [e-mail] wrote:
>reguarding a statement that dos machines have more competition between compiler
>manufacturers than the mac market does, it appears that in the near future
>that may be changing a little bit.  I found an article in macweek about a
>month ago which mentioned that metroworks C/C++ is going to have a compiler
>check flag to turn mac and powerPC binary compilation on and off.  The same
>compiler would use one set of source code and compile a program for either
>the mac, the powerPC, or (if I understood correctly) both at once (fat
>binaries).
>The article went on to mention that the author thought it was both faster
>and easier to use than its competitor.  Seeing how it bills itself as
>a native c++ compiler for the mac I can only think of one competitor.
>        I am anxiously waiting to see what happens, how easy it really
>is (or isn't), and if they have a competitive upgrade offer.

Yes, I saw notes of the compiler to-be. I'm very interested in it and will
search for it when I hit MacWorld (or the Developer's conference). If it
looks better (i.e. more full featured), then I just might abandon my SC++
for MWC++(?). From what I've read, Metroworks has some pretty good
expertise in the compiler market - but I don't have first hand experience
with their products.

Greg


--
Greg Ferguson                   email:  [e-mail]
Programmer/Engineer             voice:  602.952.3623
World Marketing
Motorola, SPS

*****************************************************************
In a classic case of one thing leading to another, seven men aged
eighteen to twenty-nine received jail sentences of three to four years in
Kingston-on-Thames, England, in 1979 after a fight that started when one
of the men threw a french fry at another while they stood waiting for a
train.
        - Weird news #616
*****************************************************************












Path: ucivax!gateway
From: [e-mail] (Jim Van Peursem)
Subject: Re: Got a list of bugs in TC6?
Message-ID: <[e-mail]>
In-Reply-To: Your message of "09 Dec 1993 22:42:25 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 10 Dec 93 17:51:14 GMT


>Subject:  Got a list of bugs in TC6?
>While we are on the subject of bugs in Think C, does anyone have a
>comprehensive list of the current bugs in Think C 6?

  The list from Symantec is public and is available from sumex, etc.

+---------------------------------------------------------------+
| Jim Van Peursem - Ph.D. Student - Ham Radio -> KE0PH          |
| Department of Electrical Engineering and Computer Engineering |
| Iowa State University - Ames, IA 50011                        |
| internet - [e-mail]  -or-  [e-mail]    |
+---------------------------------------------------------------+










Path: ucivax!gateway
From: [e-mail] (George Tempel)
Subject: c++ libs available
Message-ID: <[e-mail]>
Content-transfer-encoding: 7BIT
Newsgroups: fa.think-c
Lines: 12
Date: 10 Dec 93 20:01:54 GMT

                      c++ libs available
Thanks to those who tried to help me find some
available C++ libraries.

The most interesting batch of stuff was found via Mosaic:
http://info.desy.de/user/projects/C++.html

check in there! Too much for me to detail.

george tempel












Path: ucivax!gateway
From: [e-mail] (Pete Gontier)
Subject: Re: reporting syntax errors
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Rich Siegel" at Dec 10, 93 02:21:05 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1389
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 36
Date: 10 Dec 93 20:03:24 GMT

Dana wrote:

> > be careful what
> > you ask for, the gods will surely find a may to grant it
> > which will make you regret ever having had the nerve to
> > raise your voice.

Rich wrote:

> Indeed, and it might appear that the present Symantec C++ compiler is
> an example of this principle in action.

Folks, I'm sorry to do this again, but I really must take this
opportunity to say "I told you so..." once more.

Remember when Symantec was posting things on the net asking what we
wanted from the next release of their compiler, and I was the
crusader who wanted them to fix the linker and ignore C++?  99% of
you laughed and called me unrealistic, that C++ would be so much more
of a productivity enhancement...

I was also the one to be posting that THINK C 5 would be the last
usable version because the company had lost Kahl and acqired Zortech.
And wasn't I right about that, too? (Please, THINK C 6 is not a new
version. And it has more bugs anyway.)

Symantec should hire me as their in-house curmudgeon. I'd take the
job if they gave me project veto power. I'd be their short-term
thinking's worst nightmare. The stock price would plunge for six
months. Dozens of suits with no creativity would lose their Lexi.
After six months the company'd start shipping great products...

Ah, we all need to fantasize sometimes...

--
 Pete Gontier // EC Technology // [e-mail]










Path: ucivax!gateway
From: [e-mail] ("Jeffrey K. Carney")
Subject: GetFInfo Directory troubles
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 22
Date: 10 Dec 93 21:23:28 GMT

I'm pleading again!

Whether I use FSpGetFIno, HGetFInfo, or PBHGetFInfo, I get the expected
results when the object in question is a file; but when it's a directory,
all I get is an fnf error.  Why this should be, since I get its data from
CustomGetFile, I don't know.  The thing is there; then it's not there.

Does anyone have a solution?  Please contact me even if you're just
stumped.  This is really bumming me out.
TIA

+=================================================================+
|                           Jeff Carney                           |
|                          Snow  College                          |
|                        Ephraim, UT 84627                        |
|                        [e-mail]                        |
|                                                                 |
|"Everything that deceives appears to cast a spell upon the mind."|
|                              Plato                              |
+=================================================================+












Path: ucivax!gateway
From: [e-mail] (Pete Gontier)
Subject: Re: GetFInfo Directory troubles
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Jeffrey K. Carney" at Dec 10, 93 09:23:28 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 448
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 12
Date: 10 Dec 93 23:13:34 GMT

> Whether I use FSpGetFIno, HGetFInfo, or PBHGetFInfo, I get the expected
> results when the object in question is a file; but when it's a directory,
> all I get is an fnf error.

Note the capital 'F' in all the calls you have tried. Those calls
work for files, not directories. PBGetCatInfo isn't entirely
obsolete. :-)

--
 Pete Gontier // EC Technology // [e-mail]

 Symantec C++ a "Bjarne Burner"? Yeah, I'd be pretty burned up, too!










Path: ucivax!gateway
From: [e-mail] ("Jeffrey K. Carney")
Subject: SUMMARY: GetFInfo Directory Troubles
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 25
Date: 11 Dec 93 00:26:23 GMT

Thanks to all who helped.  Yes, PBGetCatInfo seems to solve the troubles.
And to all those who thought I was a twerp for even trying the other
routines, let me quote from the New IM:

"You can use the FSpGetFInfo function to obtain the Finder information
about a file or directory."  (2-160)

Well, as many of you know, this does not work for directories after all.
What you get instead is error -43 (fnf).  PBGetCatInfo, on the other hand,
does the trick for both files and directories, as does its mate,
PBSetCatInfo.

And if any of you didn't know this already, I hope you benefit from all this.

+=================================================================+
|                           Jeff Carney                           |
|                          Snow  College                          |
|                        Ephraim, UT 84627                        |
|                        [e-mail]                        |
|                                                                 |
|"Everything that deceives appears to cast a spell upon the mind."|
|                              Plato                              |
+=================================================================+












Path: ucivax!gateway
From: [e-mail]
Subject: Re: UNSubscribe
Errors-To: <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: America Online Mailer
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 1
Date: 11 Dec 93 12:19:08 GMT

Please UNsubscribe me. Thanks you










Path: ucivax!gateway
From: [e-mail]
Subject: unsubscribe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 11 Dec 93 19:02:45 GMT

unsubscribe think-c










Path: ucivax!gateway
From: [e-mail] (Rodolfo Cardarelli)
Subject: Merry Xmas + FORTRAN question
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 13 Dec 93 08:56:25 GMT

I have been using FORTRAN 77 on several platforms for years, now, and I'd
like to port code and techniques that I know on the MAC. Could you tell me if t
here's a FORTRAN compiler that I can use in conjunction with TC6? I don't need
(and actually I don't really want...) a compiler that has glue to the Toolbox,
because I believe that C is much more suitable for GUIs; I'd be happy with a si
mple, straightforward F77 whose objects are callable from TC6 main routines.
This is my wish for Xmas|||
Merry Xmas to you all.
Rodolfo










Path: ucivax!gateway
From: [e-mail]
Subject: Communicating with an External Device through the printer port
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 13 Dec 93 14:12:55 GMT


Id like to communicate with an external device with the printer port on my mac.
The external device has a standard RS232 connection and I have the cables and
hardware. Software is the problem. Does anyone have any advice on how I can
go about producing the software? i.e., which manager should be used, what
problems might occur and how to avoid them, how does one control the printer
port or any other RS232-compatible port?

I have worked with ThinkC before, but never to control any external device.

-Taquin

PS: Excuse the multiple copies of this mail in usenet. I wrote articles there
before I realised that this is a mailing group.










Path: ucivax!gateway
From: [e-mail] (Jim Lynch)
Subject: Re: reporting syntax errors
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 50
Date: 13 Dec 93 14:20:33 GMT

>Dana wrote:
>
>> > be careful what
>> > you ask for, the gods will surely find a may to grant it
>> > which will make you regret ever having had the nerve to
>> > raise your voice.
>
>Rich wrote:
>
>> Indeed, and it might appear that the present Symantec C++ compiler is
>> an example of this principle in action.
>
>Folks, I'm sorry to do this again, but I really must take this
>opportunity to say "I told you so..." once more.
>
>Remember when Symantec was posting things on the net asking what we
>wanted from the next release of their compiler, and I was the
>crusader who wanted them to fix the linker and ignore C++?  99% of
>you laughed and called me unrealistic, that C++ would be so much more
>of a productivity enhancement...
>
>I was also the one to be posting that THINK C 5 would be the last
>usable version because the company had lost Kahl and acqired Zortech.
>And wasn't I right about that, too? (Please, THINK C 6 is not a new
>version. And it has more bugs anyway.)
>
>Symantec should hire me as their in-house curmudgeon. I'd take the
>job if they gave me project veto power. I'd be their short-term
>thinking's worst nightmare. The stock price would plunge for six
>months. Dozens of suits with no creativity would lose their Lexi.
>After six months the company'd start shipping great products...
>
>Ah, we all need to fantasize sometimes...
>
>--
> Pete Gontier // EC Technology // [e-mail]

Pete, put your stock prices where your mouth is. Start your own macintosh
compiler vending company. If you think you know the right thing to do, then
by all possible means, do it.

Creativity? Not (much of) a flame here, but the creativity goes into the
user interface. Compilers have pretty much been carved into standard fare
for the past 25 years. First use that standard to create a CORRECT
compiler. Only then should creativity in code generation be applied to get
faster and/or smaller code. But I digress and lighten up: I agree with you
that creativity should be applied to the PRODUCT, not their own FINANCE.

-Jim











Path: ucivax!gateway
From: [e-mail] ("Mark D. Nagel")
Subject: ADMIN: semi-periodic reminder about requests...
Message-ID: <28728.755799477@rdatasys>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: Relational Data Systems, Irvine, CA
Lines: 32
Date: 13 Dec 93 16:22:41 GMT
Phone: [phone]

Just a little reminder to everyone:

    If your message will be worded like:

        "Please unsubscribe me."

    or like:

        "Please change my address."

    or any other similar _administrative_ request, please,
    please, PLEASE send your message to:


        ---> [e-mail] <---
             ^^^^^^^^^^^^^^^


    If you send the message to the actual list address, then
    over 500 readers will receive it, possibly even including
    myself.  I make it a policy to completely ignore any such
    request I see on the list, so doing so is entirely useless
    (other than generating these reminders).

    Also, all administrative requests are processed manually at
    this time, so it may take a day or two, sometimes even
    three, for me to respond.  Please don't mistake this delay
    for being ignored.

Happy Holidays.

Mark










Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Re: fix the bugs first (was reporting syntax errors)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 32
Date: 13 Dec 93 16:32:47 GMT

>  My comment was based on the fact that developers are very dissappointed
>with the number of bugs in the compiler. It would be suicide to leave these
>unfixed and release a new version. Sure there are going to be bugs in every
>compiler, from release to resease. But they simply cannot (or should not if
>they have any brains in management) leave the product as buggy as it is.

Agreed, but unfortunately it is often better to leave known bugs in a
piece of software than, by trying to fix them, create unknown bugs. This
is expecially difficult in compilers where there is so much context-sensitivity
and a bug may manifest itself under only a few obscure circumstances.

One of the things I haven't seen mentioned is that good error-reporting
in a c++ compiler is a very hard problem; C++ requires so much state
to parse properly that generally when something fails, all that is known
is that some particular path through the parse tree failed, and backing
up enough is a hard problem. In other words, the compiler may have to
maintain as much state to report an error correctly as it does to compile
correctly. This would certainly slow things down. Otherwise there is the
common problem on reporting an error in the wrong place (where the actual
error might have happened many lines ago). There's been a lot of discussion
in the interviews in C++ Report about the difficulty of compiling C++ now.

I guess I'm trying to say that there are very sharp people working on this;
C++ certainly deserves some criticism and errors should be pointed out, but
these are hard problems to solve and it doesn't really help to point out
obvious solutions; if they were obvious, they would be implemented by now.
-Paul-



Internet: [e-mail]       NewtonMail: [e-mail]











Path: ucivax!gateway
From: [e-mail] (Michael Sattler)
Subject: Re: unsubscribe
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 14
Date: 13 Dec 93 16:51:48 GMT

At  7:02 PM 12/11/93 +0000, [e-mail] wrote:
>unsubscribe think-c

try sending to think-c-request


-----------------------------------------------------------------------------
Michael S. Sattler         [e-mail]        [phone]
Digital Jungle Software    Encrypt now; ask me how.   (finger for PGP key)

               All that is required for evil to triumph is
                for {wo}men of good will to do nothing.












Path: ucivax!gateway
From: [e-mail] (Jim Van Peursem)
Subject: Re: Communicating with an External Device through the printer port
Message-ID: <[e-mail]>
In-Reply-To: Your message of "13 Dec 1993 14:12:55 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 13 Dec 93 17:26:23 GMT


>Id like to communicate with an external device with the printer port on my mac.
>The external device has a standard RS232 connection and I have the cables and
>hardware. Software is the problem. Does anyone have any advice on how I can
>go about producing the software? i.e., which manager should be used, what
>problems might occur and how to avoid them, how does one control the printer
>port or any other RS232-compatible port?

  How about reading about the Serial Driver in Inside Macintosh?

+---------------------------------------------------------------+
| Jim Van Peursem - Ph.D. Student - Ham Radio -> KE0PH          |
| Department of Electrical Engineering and Computer Engineering |
| Iowa State University - Ames, IA 50011                        |
| internet - [e-mail]  -or-  [e-mail]    |
+---------------------------------------------------------------+










Path: ucivax!gateway
From: [e-mail]
Subject: unsubscribe
Via: uk.ac.birmingham.computer-science; Mon, 13 Dec 1993 17:14:32 +0000
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 13 Dec 93 17:47:56 GMT

Please unsubscribe me now, thanx.










Path: ucivax!gateway
From: [e-mail] (BIESECKER)
Subject: RE: unsubscribe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 13 Dec 93 18:31:40 GMT

AAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!
_______________________________________________________________________________
From: [e-mail] on Mon, Dec 13, 1993
08:18
Subject: unsubscribe
To: [e-mail]

Please unsubscribe me now, thanx.











Path: ucivax!gateway
From: [e-mail] (Pete Gontier)
Subject: Re: reporting syntax errors
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Jim Lynch" at Dec 13, 93 02:20:33 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1178
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 27
Date: 13 Dec 93 19:00:55 GMT

> Pete, put your stock prices where your mouth is. Start your own
> macintosh compiler vending company. If you think you know the right
> thing to do, then by all possible means, do it.

This, as you know, is an unrealistic response. Symantec is using
money gathered in other markets to buy up inferior products targetted
at markets it does not understand and failing to clean them up before
ship. This has very little to do with whatever capital I might have
to start my own compiler vendor.

If I had money, this is what I'd do: buy up some former THINK
engineers.  And whaddya know, there's a company that's done that...
so I need not bother.

> Creativity? Not (much of) a flame here, but the creativity goes into
> the user interface. Compilers have pretty much been carved into
> standard fare for the past 25 years. First use that standard to
> create a CORRECT compiler. Only then should creativity in code
> generation be applied to get faster and/or smaller code.

This is the old view of software engineering. Yourdon would not be
pleased.

--
 Pete Gontier // EC Technology // [e-mail]

 Symantec C++ a "Bjarne Burner"? Yeah, I'd be pretty burned up, too!










Path: ucivax!gateway
From: [e-mail] (Reuben Gellman)
Subject: strtod problem
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.4 PL22]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 262
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 8
Date: 13 Dec 93 20:38:23 GMT

Someone recently mentioned that the lib func "strtod" is broken in
TC6. Is this also true for TC5? How does the problem show up? Is the
same true of strtok? I ask because I have some bizarre bugs which may
be related to these.
Thx
Reuben Gellman
[e-mail]











Path: ucivax!gateway
From: [e-mail] ("Kenneth F. Miller")
Subject: How do you unsubscribe from this list?  Thanks.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 0
Date: 13 Dec 93 22:35:34 GMT











Path: ucivax!gateway
From: [e-mail] (Mike Ouradnik)
Subject: NoteAlert()
Message-ID: <QD0DCB0A@ouradnik>
Newsgroups: fa.think-c
Lines: 17
Date: 14 Dec 93 14:21:18 GMT

Another Question from the primer:

Can anyone tell me why the CautionAlert(),NoteAlert(),StopAlert() routines
would be sticking in the ICON with the ID one less than IM:ToolBox indicates?

That is:
CautionAlert() shows the Note ICON (1),
NoteAlert()    shows the Stop ICON (0),
StopAlert()    shows nothing (-1?).

There are no ICON resources in my file and even when I create ICONs with IDs
0, 1, and 2 the wrong ones get put up.

Thanks

p.s. running TC5, I'll check it without any extensions tonight.











Path: ucivax!gateway
From: [e-mail] (Dave MacLachlan)
Subject: Weird & Wonderful Bus Errors with C++6.01
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 14 Dec 93 16:44:49 GMT

Has anybody been receiving weird and wonderful bus errors when copding with C++6.01? I've got programs that will comile just fine with MPW C++ (albeit slowly), but throw beautiful bus erros up on my screen with THINK...not impressed at all.
I hate to blame compilers, but after spending about 60 hours trying to track these down, I tihnk that THINK may have some serious problems. It always seems to bus error on a MOVE A0,(A0) and A0 is always some nice value like $7ffc0001....

Anybody?


--------------------------------------------------------------------------------
Dave MacLachlan            He hacks, he cracks and he hacky-sacks!
[e-mail]        University Of Victoria, Victoria B.C.
NightFall Software Inc.         "Only the good die young!" - Billy Joel












Path: ucivax!gateway
From: [e-mail] ("David A. den Boer")
Subject: Re: Weird & Wonderful Bus Errors with C++6.01
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 19
Date: 15 Dec 93 14:50:07 GMT

>Has anybody been receiving weird and wonderful bus errors when copding with
>C++6.01? I've got programs that will comile just fine with MPW C++ (albeit
>slowly), but throw beautiful bus erros up on my screen with THINK...not
>impressed at all.

Same type of errors (intermittently though), but what I am finding is that I
will occasionally get segment loader errors when using a function like strcmp
or strlen at one moment, and if I leave it alone for a while, I no longer get
the error.  It's happened many times in the last few weeks.

Time for a look at Metrowerks compiler! ($399 gets you C, C++, and Pascal that
will compile on a Mac or PowerPC, and can do fat binaries!)


David A. denBoer
University of Manitoba Computer Services
[e-mail]












Path: ucivax!gateway
From: [e-mail] (Systems Manager)
Subject: hello
Message-ID: <2en8rq$[e-mail]>
Newsgroups: fa.think-c
Organization: us
Lines: 1
Date: 15 Dec 93 15:01:35 GMT

Hi there.










Path: ucivax!gateway
From: [e-mail]
Subject: test(2)
Message-ID: <2en8ub$[e-mail]>
Newsgroups: fa.think-c
Organization: Imperial Cancer Research Fund
Lines: 1
Date: 15 Dec 93 15:02:23 GMT

Hi there










Path: ucivax!gateway
From: [e-mail]
Subject: test (3)
Message-ID: <2en95t$[e-mail]>
Newsgroups: fa.think-c
Organization: ICRF Gateway
Lines: 1
Date: 15 Dec 93 15:06:58 GMT

testing.....










Path: ucivax!gateway
From: [e-mail] ("David A. den Boer")
Subject: Metrowerks Code Warrior
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 26
Date: 15 Dec 93 19:25:09 GMT

I have been asked for this information by a few, and rather than be deluged with
requests, here is some infor for all to peruse.

Metrowerks Code Warrior
- Can code in Pascal, C or C++
- compile for 680x0 or PowerPC Macs
- fastest compilation times (16 hrs with Risc SDK from Apple vs 11.5
minutes with code warrior
- still in beta, but company will sell, and free upgrades you later
- three different packages : MacOnly, PPC only, and Both $199, $299, $399
I think these prices are Canadian, and may not accurately reflect what it could
cost you.  No guarantees.

Metrowerks Inc.
1500 du College
Suite 300
St. Laurent, Quebec
H4L 5O6, CANADA
[phone]


--
David A. denBoer                                             Computer Services
[e-mail]                                 University of Manitoba












Path: ucivax!gateway
From: [e-mail] ("James E. O'Dell")
Subject: Re:[2] Weird & Wonderful Bus Errors with C++6.01
Message-ID: <[e-mail]>
X-Mailer: Mac/gnuucp Mail Reader v6.12
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: Fort Pond Research
Lines: 10
Date: 16 Dec 93 07:48:30 GMT

.....

>Time for a look at Metrowerks compiler! ($399 gets you C, C++, and Pascal
that
>will compile on a Mac or PowerPC, and can do fat binaries!)

Hmmm, anybody know if Metrowerks offers a sidegrade to THINK users?
This might be the time for them to offer one.

Jim










Path: ucivax!gateway
From: [e-mail] (Rodolfo Cardarelli)
Subject: Compilers war
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 16 Dec 93 13:04:45 GMT

A metrowerk competitive upgrade for TC6 users would be very well accepted, I
guess. But what about compatibility with TCL, or with code written in TC?
Without that, the upgrade is not worth.


Rodolfo










Path: ucivax!gateway
From: [e-mail] (William L Menninger)
Subject: Directory searching functions wanted'
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 16 Dec 93 16:03:36 GMT

I'd like to do a couple (hopefully) simple operations in Think C. I have
a lot of experience with MS-DOS, AmigaDOS, and Unix, but not very much
with Think C or Macintosh programming.  I'd like to have a function much
like Borland's findfirst()/findnext() combo that returns, one by one (or
in some sort of linked list), the names of all of the files in a given
folder.  Also, I'd like a function that will return stats about a file,
such as last modified date, etc.  Preferrably, each of these functions
would take simple C-string file/folder names as arguments, e.g.
"HD:Personal Folder:Frank:Data".  Can someone give me some
simple/concise examples of how to write such functions?

Reply to:  [e-mail]  (I am not on the Think C mailing list)

-Will Menninger
graduate student











Path: ucivax!gateway
From: [e-mail] (Jim Van Peursem)
Subject: Re: Compilers war
Message-ID: <[e-mail]>
In-Reply-To: Your message of "16 Dec 1993 13:04:45 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 16 Dec 93 16:25:56 GMT


>A metrowerk competitive upgrade for TC6 users would be very well accepted, I
>guess. But what about compatibility with TCL, or with code written in TC?
>Without that, the upgrade is not worth.

  I disagree. Many of us are sick of the way Symantec has handled it's
compilers since they bought Think. If a side-grade option was available,
I'd probably buy it today. But otherwise, I'm going to save my money and
see what my peers think of it before I sink my cash into another lemon.

  As for TCL compatibility, I have my doubts. TCL assumes some features
of TC that may not be present in CW (handle based objects, etc). They do
ship their own class library though, and all I've heard about it is that
it is "interesting". Wait and see I guess.

  I would assume that most TC code should compile fine on CW though.

  Disclaimer: This is just what I've heard on the net. I haven't seen
the product myself, so I don't know for sure.

+---------------------------------------------------------------+
| Jim Van Peursem - Ph.D. Student - Ham Radio -> KE0PH          |
| Department of Electrical Engineering and Computer Engineering |
| Iowa State University - Ames, IA 50011                        |
| internet - [e-mail]  -or-  [e-mail]    |
+---------------------------------------------------------------+










Path: ucivax!gateway
From: [e-mail] (Dana S Emery)
Subject: Re: 2] Weird & Wonderful Bus Errors with C++6.01
Message-ID: <[e-mail]>
In-Reply-To: Your message <[e-mail]> of 16 Dec 93
 07:48:30 GMT
Content-Type: TEXT/plain; charset=US-ASCII
Newsgroups: fa.think-c
Lines: 14
Date: 16 Dec 93 16:26:36 GMT

>   Hmmm, anybody know if Metrowerks offers a sidegrade to
>   THINK users? This might be the time for them to offer
>   one.

My schools bookstore is hot to carry them, provided an edu
price were available, M would be well advised to consider
that early, teachers make course decisions quite far in
advance, and bookstores like to plan their purchases early
enough to ensure stock will be on hand for the course.

Does M have an email address?
--
dana s emery <[e-mail]>











Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re: Compilers war
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Jim Van Peursem" at Dec 16, 93 04:25:56 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1558
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 34
Date: 16 Dec 93 17:30:41 GMT

>
> >A metrowerk competitive upgrade for TC6 users would be very well accepted, I
> >guess. But what about compatibility with TCL, or with code written in TC?
> >Without that, the upgrade is not worth.
>
>   I disagree. Many of us are sick of the way Symantec has handled it's
> compilers since they bought Think. If a side-grade option was available,
> I'd probably buy it today. But otherwise, I'm going to save my money and
> see what my peers think of it before I sink my cash into another lemon.
>
>   As for TCL compatibility, I have my doubts. TCL assumes some features
> of TC that may not be present in CW (handle based objects, etc). They do
> ship their own class library though, and all I've heard about it is that
> it is "interesting". Wait and see I guess.
>
>   I would assume that most TC code should compile fine on CW though.

Seconded, seconded, and seconded. TCL compatability is not a big deal,
because the installed TCL base is not that large, Code Warrior includes
its own class library, and when the pointer-based TCL becomes available,
there's an outside change that it'll work with Code Warrior.

Currently extant THINK C code works fine, assuming you write it
portably. Code Warrior provides an inline assembler, but the syntax
model is different (generally for the better). I've had minimal
problems porting various pieces of THINK C code, with zero to minimal
change.

I don't know Metrowerks' policy regarding competitive upgrades and/or
educational pricing. I have placed inquiries and will report as soon
as I know.

R.











Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Re: Compilers war
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 16 Dec 93 18:19:32 GMT

Actually I'm also all in favor of "sidegrade" arrangments. Arrangments
like this in the PC universe allowed me to buy Borland C++ 3.1 originally,
then get a sideways upgrade to Visual C++ for cheap, so I could work with
both and compare/contrast. Symantec has a similar arrangement for a "sidegrade"
to the Symantec C++ package. Plus, of course, you can get inexpensive upgrades
to go to Borland 4.0, etc.

This is known as "leveraging off your initial investment"   : )
The only downside is that the docs for all these packages take up yards and
yards of shelf space and you will need an awfully big hard disk to keep
all the packages installed.

-Paul-
Internet: [e-mail]       NewtonMail: [e-mail]











Path: ucivax!gateway
From: [e-mail] (Dave Nebinger)
Subject: Re: Compilers war
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 15
Date: 16 Dec 93 18:39:29 GMT

>The only downside is that the docs for all these packages take up yards and
>yards of shelf space and you will need an awfully big hard disk to keep
>all the packages installed.

  If CodeWarrior is all that they say it is, it would be worth those minor
problems.  ;-)


============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>












Path: ucivax!gateway
From: [e-mail] (Andrew Dent)
Subject: Re: Compilers war
Message-ID: <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
Newsgroups: fa.think-c
Lines: 15
Date: 16 Dec 93 23:28:29 GMT

I'
I've heard one rumour that Greg Dow (author of TCL) joined Metrowerks
and so I'd expect a lot of similarity in the class libraries.

There's not a lot to do to remove handle-based dependencies anyway, unless
you've written grotty code that treats your objects as handle-based
structs and dereferences them as such.

The instantiation by name etc. is all buried in TCL classes and I'd expect
some comparable mechanism, if they have resource-driven views.

Andy Dent (A.D. Software - Mac & VAX programming)
94 Bermuda Dve, BALLAJURA  Western Australia  6066
Phone/Fax: [phone] (local)  [phone] (International)
       Internet: [e-mail]    Compuserve: 100033,3241










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re: Compilers war
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Daniel Sears" at Dec 16, 93 04:25:19 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 354
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 14
Date: 17 Dec 93 03:45:54 GMT


> You said that it has an inline assembler.  Greg said
> that it was for functions only not for blocks ala ThinkC.

That's correct.

> (It had one feature that vi had years ago which you
> might add to BBedit: visual parenthesis matching.)

Are you referring to the feature where it flashes the matching
paren/brace/bracket? BBEdit does that now.

R.











Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re: Compilers war (fwd)
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.4 PL21]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1308
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 52
Date: 17 Dec 93 16:21:52 GMT

Forwarded message:
From siegel Fri Dec 17 08:21:38 1993
Subject: Re: Compilers war
To: [e-mail]
Date: Fri, 17 Dec 1993 08:21:38 -0800 (PST)
In-Reply-To: <[e-mail]> from "[e-mail]" at Dec 17, 93 09:31:09 am
X-Mailer: ELM [version 2.4 PL21]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 911


> >> You said that it has an inline assembler.  Greg said
> >> that it was for functions only not for blocks ala ThinkC.
> >
> >That's correct.
>
> I understand ThinkC's inline assembler and have used it, but I don't
> understand the statement that metroworks assembler is for functions
> only.  I can't seem to picture how that would (or wouldn't) work.
> Can you explain the difference between the usage of each?
>     I know thinkC's code would be something like:
> asm    {
>     move.l a0, a1;
>     }
>
> How would metroworks be different?

In THINK C, a function might look like this:

void foo(short c)
{
    asm
    {
        move.w c, d3 ; do some stuff
    }
}

Such functions
In Metrowerks C/68K, functions are declared 'asm', as in

asm void foo(short c)
{
    move.w    c, d3
}

Functions declared 'asm' cannot contain C code or local declarations,
but can have arguments (and can reference those arguments symbolically).

R.











Path: ucivax!gateway
From: [e-mail] ("Fred G. Martin")
Subject: problem getting valid FSSpec from OpenDocument event
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 71
X-Mts: smtp
Date: 17 Dec 93 18:11:36 GMT

Hello all,

I'm having trouble getting valid data in the FSSpec returned by the
AEGetNthPtr call in my Open Document event handler.  I get a valid
filename in the FSSpec, but the volume number comes up -1 every time.

Except.  The weird thing is if I put the file to be opened on a floppy
disk, and then double-click on it, the vRefNum is correct and my
application can open it properly.  Hmmm, I have no idea what's going
on.

Here's the code I'm using (Think C 5.0.2).  If anyone can shed any
light on this situation, I would be most appreciative.

    -Fred

pascal OSErr DoOpenDoc( AppleEvent theAE, AppleEvent reply, long refCon)
{
    FSSpec    myFSS;
    SFReply     mySFReply;
    AEDescList  docList;
    OSErr       myErr;
    long        index, itemsInList;
    Size        actualSize;
    AEKeyword   keywd;
    DescType    returnedType;
    int         i;

    /* get the direct parameter---a descriptor list---and put it into docList */
    myErr= AEGetParamDesc(&theAE, keyDirectObject, typeAEList, &docList);

    if (myErr != noErr) {
        ParamText("\pError calling AEGetParamDesc in DoOpenDoc","","","");
        NoteAlert(kTellUserAlert, 0L);
        return;
    }

    /* check for missing required parameters */
    /* not implemented */

    /* count the number of descriptor records in the list */
    myErr= AECountItems(&docList, &itemsInList);

    /* now get each descriptor record from the list, coerce the returned */
    /* data to an FSSpec record, and open the associated file */

    /* well, we'll just do it for the first and ignore multiple open-files. */
    myErr= AEGetNthPtr( &docList, 1L, typeFSS, &keywd, &returnedType,
                        (Ptr)&myFSS,
                        (Size)sizeof(myFSS), &actualSize);


    if (myErr != noErr) {
        ParamText("\pError calling AEGetNthPtr in DoOpenDoc","","","");
        NoteAlert(kTellUserAlert, 0L);
        return;
    }

    /* open the file by passing an SFReply to DoFileDownload */
    mySFReply.vRefNum= myFSS.vRefNum;

    mySFReply.fName[0]= myFSS.name[0];
    for (i=1; i<= myFSS.name[0]; i++)
        mySFReply.fName[i]= myFSS.name[i];
    mySFReply.good= TRUE;

    DoFileDownload(mySFReply);

}












Path: ucivax!gateway
From: [e-mail] (Greg Ferguson)
Subject: Re: Re:[2] Weird & Wonderful Bus Errors with C++6.01
Message-ID: <9312172107.AB03260@vulture.>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 33
Date: 17 Dec 93 21:08:14 GMT

At  7:48 AM 12/16/93 +0000, James E. O'Dell wrote:
>.....
>
>>Time for a look at Metrowerks compiler! ($399 gets you C, C++, and Pascal
>that
>>will compile on a Mac or PowerPC, and can do fat binaries!)
>
>Hmmm, anybody know if Metrowerks offers a sidegrade to THINK users?
>This might be the time for them to offer one.

I agree. I haven't seen their compiler, but from what I've read it's nice.
I'm tired of having a kludged editor (running CMaster) and the external
editor mechanism seems very slow. The whole Symantec package just doesn't
seem as solid as the Borland tools I used to use.

Greg

--

Greg Ferguson

[e-mail]
Desktop Networking Systems
World Marketing
Motorola, SPS


=============================================================
      We haven't inherited the earth from our ancestors.
        We've borrowed it from our children instead.
=============================================================












Path: ucivax!gateway
From: [e-mail] (Mike Ouradnik)
Subject: Re: NoteAlert()
Message-ID: <QD123C5D@ouradnik>
In-Reply-To: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 17 Dec 93 23:11:05 GMT



Thanks, Jeff C, for your response to my NoteAlert() problem.  Don't worry
about talking down, I have been doing C programming for several years but
I'm brand new to Mac stuff.  And of course 90% of programming problems are
from overlooking the most obvious...

I was supplying the required Alert box ID, and I did double check the system
file for the expected ICONs.

It appears my Talking Moose ( have you seen the Moose?) is sticking his big
nose in somewhere.  When the Moose is unloaded everything works fine.  In
case you've forgotten, I was seeing the ICON with ID# 0 (Stop ICON) when
calling NoteAlert(128,nil) even though IM clearly states I should see ICON
ID#1 (Note ICON), and CautionAlert() would show the Note ICON.

Any ideas out there?

-Mike













Path: ucivax!gateway
From: [e-mail] (William L Menninger)
Subject: Thanks!
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 18 Dec 93 14:01:46 GMT

What a supportive group this is.  I got several replies to my request
for help with a directory parsing function, all of which are
appreciated.  Mostly, people told me to get the book Inside Mac:  Files,
which I probably won't do, since I don't plan to program on the Mac
regularly, but it's nice to know what the serious programmers use in
case I get more involved.  While I haven't implemented anything yet, I
did want to thank the following people for taking the time to give me
some advice:

E. Huff, T. Brown, D. Emery, and A. Wood.

I don't think I need any more information at the present time.  Thanks
again.

-Will Menninger
graduate student











Path: ucivax!gateway
From: [e-mail] (William L Menninger)
Subject: One more kudos
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 18 Dec 93 14:39:20 GMT

Oops.  I forgot to mention one of the people who sent me a nice detailed
reply about directory searching, and he was the first to reply, too.
Oh, the utter irony of it.  Just so he doesn't feel slighted:  Thanks to
Jeffrey Carney!

-Will











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Weird & Wonderful Bus Errors with C++6.01
Errors-To: <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: America Online Mailer
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 23
Date: 20 Dec 93 02:14:03 GMT

>Date:  93-12-14 11:59:28 EST
>From:  [e-mail]
>Subj:  Weird & Wonderful Bus Errors with C++6.01
>
>Has anybody been receiving weird and wonderful bus errors
>xwhen copding with C++6.01? I've got programs that will compile
>just fine with MPW C++ (albeit slowly), but throw beautiful bus
>errors up on my screen with THINK...not impressed at all.
>I hate to blame compilers, but after spending about 60 hours
>trying to track these down, I tihnk that THINK may have some serious
>problems. It always seems to bus error on a MOVE A0,(A0) and A0 is
>always some nice value like $7ffc0001....

I have been having similar bus error problems, but figured it was the fact
that my INIT was doing some somewhat unnatural acts.  I don't know about
your errors, but mine seem to be sporadic and always have a large number
($4nnnnnnn).

I don't think you are alone....
--------------------------------------------------------------------------
Lloyd Sargent
[e-mail]
Canna Software Development         "Ack, Ack, thpppt..." - Bill the Gates










Path: ucivax!gateway
From: [e-mail] ("B. Kirsch")
Subject: SFGetFile FileFilterProc Question
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 69
Date: 20 Dec 93 16:04:17 GMT

Hello,

I want to create a file filter for SFGetFile that will not only filter files
with particular file types, but also open the file to read the header to see
if it is in a particular format.  If it is not that format, remove it from
list.  It seems that I am not getting passed the correct ioVRefNum from the
fileParam structure.  The ioNamePtr is correct (as I see it in the debugger
window as the list is indexed), but I always get a -43 (File Not Found error)
when I do an FSOpen.  What am I doing wrong.

Thanks in advance.

Barry Kirsch
[e-mail]

/*------------Code Segments Follow------------*/
void DoSFGetFile()
{
    Point    where;
    SFTypeList    typeList;
    Str255    theStr;
    SFReply    theReply;

    where.h=20;  where.v=90;    /* SF dialog window position */

    SFGetFile(where,    /* put topLeft corner of dialog box here */
    0,        /* prompt always 0 on SFGetFile() */
    (FileFilterProcPtr)FileTypeFilter,    /* address of custom filter */
    -1,        /* -1 means look for any type and ignore typeList */
    typeList,    /* start of list of file types */
    0,        /* use standard dialog handler */
    &theReply);    /* put results here */

    if ( theReply.good == TRUE ) { //... user selected "Open" ...
    }
    else  { /* ... user canceled the open operation ... */
    }
}

pascal Boolean FileTypeFilter(fileParam *thePBptr )
{
#define BUFSIZE 100
    short         FileRefNum;
    short         Err;
    unsigned     char    *bufPtr;
    long        BytesToRead=BUFSIZE;


    /*Remove APPL and TEXT types from list*/
    if (( thePBptr->ioFlFndrInfo.fdType == 'APPL' )||
            ( thePBptr->ioFlFndrInfo.fdType == 'TEXT' )){
        return( TRUE );    // Don't show 'APPL' or 'TEXT' files,
    }

    /*Open file to see if it is of the correct format to display in list*/
    /*THE FOLLOWING RETURNS -43 ERROR, WHY???*/
    Err = FSOpen(&thePBptr->ioNamePtr[0], thePBptr->ioVRefNum,&FileRefNum);
    if(Err==noErr){
        bufPtr = (unsigned char *)malloc(BytesToRead);
        Err=FSRead(FileRefNum,&BytesToRead, (Ptr)bufPtr);
        if(Err==noErr){
            return(ParseBuffer(bufPtr));/*FALSE if format is valid,
                         TRUE if format is not correct*/
        }
        FSClose(FileRefNum);
        free(bufPtr);
    }
}











Path: ucivax!gateway
From: [e-mail] (Dave Nebinger)
Subject: Here we go again...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 21 Dec 93 03:03:32 GMT

  I am sure this has been around before.  How do I get the vrefnum and
dirid for my application? (In order to open files found there without
hard coding the path)

  Dave.

============================================================
Dave Nebinger                    [e-mail]
Network Manager, Biology Dept.   [e-mail]
Bowling Green State University   dnebing@bgsuopie (bitnet)
Bowling Green, OH 43403          #include <std_disclaimer.h>











Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: Here we go again...
X-Sender: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 53
Date: 21 Dec 93 07:24:00 GMT

At  3:03 AM 12/21/93 +0000, Dave Nebinger wrote:
>  I am sure this has been around before.  How do I get the vrefnum and
>dirid for my application? (In order to open files found there without
>hard coding the path)

Someone should archive this someplace. If you are using System 7, you can
just call GetProcessInformation() with kCurrentProcess. Otherwise, you can
pass the result of CurResFile(), assuming you haven't opened up any other
resource files, to the following function:

/* A Pete Resnick production ... */
OSErr RefNumToFSSpec(short refNum, FSSpecPtr fileSpec)
{
        OSErr errCode;
        long attribute;
        FCBPBRec fcb;
        Str63 tempString;

        fcb.ioCompletion = nil;
        fcb.ioNamePtr = tempString;
        fcb.ioVRefNum = 0;
        fcb.ioRefNum = refNum;
        fcb.ioFCBIndx = 0L;
        if((errCode = PBGetFCBInfoSync(&fcb)) == noErr) {
                if(TrapAvailable(_Gestalt) &&
                   Gestalt(gestaltFSAttr, &attribute) == noErr &&
                   (attribute & (1 << gestaltHasFSSpecCalls)) != 0L) {
                        errCode = FSMakeFSSpec(fcb.ioFCBVRefNum,
                                               fcb.ioFCBParID,
                                               tempString,
                                               fileSpec);
                } else {
                        fileSpec->vRefNum = fcb.ioFCBVRefNum;
                        fileSpec->parID = fcb.ioFCBParID;
                        BlockMove(tempString,
                                  fileSpec->name,
                                  tempString[0]  +  1);
                }
        }
        return(errCode);
}

Just get the dirID out of the FSSpec.

pr

--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]












Path: ucivax!gateway
From: [e-mail] (Pete Gontier)
Subject: Re: Here we go again...
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Pete Resnick" at Dec 21, 93 07:24:00 am
X-Mailer: ELM [version 2.4 PL23]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 434
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 13
Date: 21 Dec 93 17:42:41 GMT

> At  3:03 AM 12/21/93 +0000, Dave Nebinger wrote:
> >  I am sure this has been around before.  How do I get the vrefnum and
> >dirid for my application? (In order to open files found there without
> >hard coding the path)
>
> Someone should archive this someplace. [valid techniques deleted]

GetAppParms

--
 Pete Gontier // EC Technology // [e-mail]

 Symantec C++ a "Bjarne Burner"? Yeah, I'd be pretty burned up, too!










Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: Here we go again...
X-Sender: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 24
Date: 21 Dec 93 17:51:30 GMT

At  3:03 AM 12/21/93 +0000, Dave Nebinger wrote:
>  I am sure this has been around before.  How do I get the vrefnum and
>dirid for my application? (In order to open files found there without
>hard coding the path)

At  9:42 AM 12/21/93 -0800, Pete Gontier wrote:
>GetAppParms

To clarify, I take it Peter means that you should pass the returned refNum
in GetAppParms to the RefNumToFSSpec routine I sent in; GetAppParms itself
won't get you any closer to the dirID without doing something else.

I do like this better than depending on CurResFile() being correct. Good
recommendation!

pr

--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]












Path: ucivax!gateway
From: [e-mail] (Pete Gontier)
Subject: Re: Here we go again...
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Pete Resnick" at Dec 21, 93 11:48:01 am
X-Mailer: ELM [version 2.4 PL23]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 2385
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 50
Date: 21 Dec 93 18:06:34 GMT

Yes, this topic need to go in the FAQ, if it is not already there.

> At  3:03 AM 12/21/93 +0000, Dave Nebinger wrote:
> >  I am sure this has been around before.  How do I get the vrefnum and
> >dirid for my application? (In order to open files found there without
> >hard coding the path)
>
> At  9:42 AM 12/21/93 -0800, Pete Gontier wrote:
> >GetAppParms

Resnick wrote:

> To clarify, I take it Peter means that you should pass the returned
> refNum in GetAppParms to the RefNumToFSSpec routine I sent in;
> GetAppParms itself won't get you any closer to the dirID without
> doing something else.

You can go two ways after calling GetAppParms. You can call the
Resnick Productions routine, which uses the resource file reference
number to find out where the application resource file lives. Or you
can use the working directory reference number supplied by
GetAppParms.  You can use the working directory directly in most file
manager calls (although working directories are officially obsolete
and you should probably not write a lot of code that relies on your
ability to create and pass around working directories, even though
the system continues to create them in several contexts). Or you can
call GetWDInfo to get the real vRefNum and dirID from the working
directory. I like the latter method because it requires less
parameter blocking and does not rely on the (currently true) fact
that resource file reference numbers relate to "real" file reference
numbers (FCB offsets). I would not worry about this last bit except
that I know if you open a resource file a second time with a
different access specifier (read-only, for example) you get a
resource file reference number which is *not* a "real" file reference
number (FCB offset). This tells me that the fact that the first
resource file reference number corresponds to a "real" file reference
number (FCB offset) may only be a coincidence and subject to change
in the future.  (I can't recall seeing that fact documented anywhere,
and believe me, I have been prowling the documentation for years.)

> I do like this better than depending on CurResFile() being correct.
> Good recommendation!

Other schemes recommend the use of GetVol with similar caveats as
your scheme about CurResFile.

--
 Pete Gontier // EC Technology // [e-mail]

 Symantec C++ a "Bjarne Burner"? Yeah, I'd be pretty burned up, too!










Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Symantec C 6 debugging environment questions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 21 Dec 93 19:03:10 GMT

Hi all,
I know this question has been beaten to death in the past, but it is rearing
its ugly head again.

We've got a large server-like application that does a lot of asynchronous
serial I/O using the Comm Toolbox. We're in the final stages of debugging,
and troubled by sporadic crashes (a heap block gets written past its end
and the header of the next block demolished; as usual, trying to figure out
what did this is like trying to determine what the driver was thinking,
moments before a fatal car crash.)

One clue is that, when run under the Symantec C6 debugger, it seems to
never crash. Does that suggest anything to any of you? Any clues welcomed.
What are some of the differences between run-time environments that might
be helping keep the app alive under the debugger?

It probably should suggest something to me, but I'm not very suggestible,
obviously...

Thanks,
-Paul-
Internet: [e-mail]       NewtonMail: [e-mail]











Path: ucivax!gateway
From: [e-mail]
Subject: Min Memory Size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 21 Dec 93 19:52:26 GMT

I have an 8MB IIci with 7.1.  My system size has crept up to about
4MB.  The resulting 4MB isn't enough to launch both Think Project
Manager and Alpha.  I'm looking at how I can slim down my System file,
but also want to explore minimum memory sizes for TPM and Alpha.  I'll
be working on small personal programming projects, e.g. half a dozen
files of a few hundred lines.  How small can I make the TPM and Alpha
memory sizes and still have things work?  Presumably, if I cut back
too far, TPM or Alpha will complain about not being able to open a
file or TPM won't be able to do the build.

Thanks,
Barry

----------------------------------------------------
Barry Wolman            [e-mail]
Transarc Corporation        412/338-4364 (voice)
707 Grant Street        412/338-4404 (fax)
Pittsburgh, PA 15219










Path: ucivax!gateway
From: [e-mail] ("Jeffrey K. Carney")
Subject: MacTech CD
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 5
Date: 21 Dec 93 20:26:03 GMT

Has anyone purchased MacTech Mag's CD?  Is it worth it?

Jeff












Path: ucivax!gateway
From: [e-mail] (Reuben Gellman)
Subject: structure packing
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.4 PL22]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 444
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 10
Date: 21 Dec 93 20:38:26 GMT

I need to read (on a Mac) binary files created by a Pascal prog on a DOS PC.
To read the files on a PC using a Microsoft C compiler, I have to set
#pragma pack(1) before defining the structures to be read. This apparently
arranges matters so that the structs are packed on any-byte boundaries,
rather than 2-byte or 4-byte (which is the default, I think). Is there
any way to specify structure packing with TC5?

Reuben Gellman
[e-mail]











Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re: Min Memory Size
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.4 PL23]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1608
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 37
Date: 21 Dec 93 22:56:21 GMT

Forwarded message:
From siegel Tue Dec 21 14:55:57 1993
Subject: Re: Min Memory Size
To: [e-mail]
Date: Tue, 21 Dec 1993 14:55:57 -0800 (PST)
In-Reply-To: <[e-mail]> from "[e-mail]" at Dec 21, 93 07:52:26 pm
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1189


> I have an 8MB IIci with 7.1.  My system size has crept up to about
> 4MB.  The resulting 4MB isn't enough to launch both Think Project
> Manager and Alpha.  I'm looking at how I can slim down my System file,
> but also want to explore minimum memory sizes for TPM and Alpha.  I'll
> be working on small personal programming projects, e.g. half a dozen
> files of a few hundred lines.  How small can I make the TPM and Alpha
> memory sizes and still have things work?  Presumably, if I cut back
> too far, TPM or Alpha will complain about not being able to open a
> file or TPM won't be able to do the build.

I don't know if this is a viable option for you, but BBEdit 2.5 has a
smaller memory footprint than Alpha does; 512K recommended vs. 1024K
recommended. That partition doesn't have to be increased to open
additional files, since BBEdit reads text into temp memory, so if
you're running short, you just close a file or two, if necessary.
(BBEdit's minimum partition is 350K, if you're really desperate...)

R.

Rich Siegel % [e-mail]    % Principal, Bare Bones Software

"I went and shot the maximum the game laws would allow: two game
wardens, seven hunters, and a cow."











Path: ucivax!gateway
From: [e-mail] (Ramin Firoozye)
Subject: Re: MacTech CD
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]> from "Jeffrey K. Carney" at Dec 21, 93 08:26:03 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 1118
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 27
Date: 22 Dec 93 00:12:09 GMT

> Has anyone purchased MacTech Mag's CD?  Is it worth it?
>
> Jeff

I got their first release way back when. It's a nice reference although
most of the code is outdated especially in light of System 7.
It uses On-location (included with it) to index across all the MacTutor
issues. You better have a fast CD-player though otherwise it takes a *long*
time. In addition to all the MacTutor source code, there are a lot of other
goodies from DTS and (I think) some BMUG stuff. If you like programming by
example, it's a good investment. I passed on the 93 "upgrade" because the
$120+ upgrade price wasn't worth it. The upgrade included Think Reference
but I already had that. If you have Think Reference AND On-Location, you may
not appreciate the price so much.

Overall, I would get it if I didn't have access to the Internet or AppleLink.
You may also want to look into Walnut Creek's info-mac archives, BMUG's
PD-ROM, and Doctor Dobb's Journal's CD for some other programming material.

Cheers,
Ramin.

--
Ramin Firoozye'
rp&A Inc. - San Francisco, California
Internet: [e-mail] - CIS: 70751,252
--










Path: ucivax!gateway
From: [e-mail]
Subject: Re: structure packing
Errors-To: <[e-mail]>
Message-ID: <[e-mail]>
X-Mailer: America Online Mailer
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 35
Date: 22 Dec 93 00:49:45 GMT

>I need to read (on a Mac) binary files created by a Pascal prog on a DOS PC.
>To read the files on a PC using a Microsoft C compiler, I have to set
>#pragma pack(1) before defining the structures to be read.
>This apparently arranges matters so that the structs are packed on any-byte
>boundaries, rather than 2-byte or 4-byte (which is the default, I think). Is

>there any way to specify structure packing with TC5?
>
>Reuben Gellman
>[e-mail]

TC6++ has the ability to set structures to one-byte boundaries (PC
programmers tend to compact their structures due to memory/compiler
limitations -- I know having been one for 12 years).  I believe that TC5 puts
everything on word boundaries so decrease access time (accessing words on odd
addresses tend to slow the 68K down).

Personally, for binary files, whether on the Mac or PC, I prefer to read the
data in and construct the structure, rather than attempt to overlay a
structure definition on top of data.  This gives me two things:
   1) My structure can be of any size, including items that weren't in the
original structure
   2) I don't have to worry about someone coming in later and accidently
setting the flag back to word boundaries (read: fewer maintenance headaches)

Although it sounds like re-inventing the wheel, it isn't.  It's more like
"just because Johnny jumped off the bridge doesn't mean you have to..."!

Good Luck!

--------------------------------------------------------------------------
Lloyd Sargent                               "You may be right, I may be
crazy...
Internet: [e-mail]          but it might just be a lunatic you're
Canna Software Development        looking for..." Billy Joel










Path: ucivax!gateway
From: [e-mail] (Jan Hoeglund - ABB Corp Research Sweden)
Subject: ftp-sites with Mac programming examples
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 22 Dec 93 13:23:44 GMT

I would greatly appreciate if anyone could point me to ftp sites
where I could find good Macintosh programming examples written
in C or C++. While old with the Mac I am new on Internet.

Thanks,
Jan Hoeglund      Email: [e-mail]
ABB Corp Research
Sweden










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: structure packing
Message-ID: <[e-mail]>
In-Reply-To: Your message of "22 Dec 1993 00:49:45 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 22 Dec 93 16:32:21 GMT

> TC6++ has the ability to set structures to one-byte boundaries (PC
> programmers tend to compact their structures due to memory/compiler
> limitations -- I know having been one for 12 years).  I believe that TC5 puts
> everything on word boundaries so decrease access time (accessing words on odd
> addresses tend to slow the 68K down).

Accessing words on odd addresses slows the 68000 *way* down -- it
causes an unaligned access exception, which brings your program to a
screeching halt.  :-)

Unaligned accesses are permitted on 68020/030/040's, but at a speed
penalty, as Reuben indicated.

Therefore the original poster should probably adopt the method of
manually "unpacking" the packed structures from disk into memory,
unless he does not need to be compatible with the 68000.

-- Russell Finn
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Greg hampton)
Subject: Modem commands
Message-ID: <199312231520.CAA08977@wumpus>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 201
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 6
Date: 23 Dec 93 15:21:28 GMT


Hi there peoples, anyone got any code they could mail me on how to send
modem commands to my modem through C code? Like "ATDT 213 456".

Thankyou very much, Dan Hampton.
<[e-mail]>










Path: ucivax!gateway
From: [e-mail] (Terry Koyn)
Subject: Photoshop plug-in
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 25 Dec 93 01:28:09 GMT

I am wondering if anyone reading the list has experience writing
photoshop plug in modules.  I am considering adapting a THINK C 6.0
application that creates images (complete with menu bar and multiple
windows) for use as a Acquire plug-in for photoshop and I have several
questions about plug-in development:

1) Must a plug-in use a modal dialog box or can it use regular
windows and allow clicking in other windows, including one of
PhotoShop's windows?

2) Can a plug-in take control of the menu bar while running?  What
issues would there be in changing the menu bar and ensuring it is
returned to normal when returning to photoshop?

3) Can a plug-in run its own full-blown event loop?

4) What are the ramifications of using the standard memory management
routines (either directly or indirectly with a call such as NewGWorld)
to allocate and free memory in a plug-in?  How will this interact with
PhotoShop's virtual memory scheme?

Please send any replies both to the list and privately to
[e-mail] (InterNet) or C1876@UMSLVMA (BitNet).

Thanks in advance for any assistance and advice.

Terry Koyn










Path: ucivax!gateway
From: [e-mail] (The Only Cow)
Subject: Setting the Mouse Postition
X-Sender: [e-mail]
Message-ID: <[e-mail]>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Mime-Version: 1.0
Newsgroups: fa.think-c
Lines: 13
Date: 30 Dec 93 23:45:41 GMT

Is there any 'easy' way to set the position of the mouse?  I found a
little hack to do it, but it doesn't seem like it's very safe.  Any ideas?

Thanks.

-Chris

------------------------------------------------------------------------------
   "To error is human, but to really foul things up, you need a computer."
                   Send questions, comments, flames, etc. to:
                 Chris Harris / [e-mail]
                      PGP Signature availible via finger...











Path: ucivax!gateway
From: [e-mail] (Greg hampton)
Subject: sorting strings
Message-ID: <199312310335.OAA29272@wumpus>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Content-Length: 282
MIME-Version: 1.0
Newsgroups: fa.think-c
Lines: 10
Date: 31 Dec 93 03:36:05 GMT


Hi. I need somehow to sort a bunch of c or p-strings alphabetically.

I just need the references to an array of strings in what order they should
be used for a-z sorting, or actually sorting the array would be better.

Hope i haven't been to unclear.

AtDhVaAnNkCsE, Dan Hampton.